With reference to FIG. 1, the object of the present invention is more particularly to be able to boot at least one first computer (A) using the operating system (OS) of a second computer (B), for example in order to network a plurality of ‘slave’ terminals or even in case of partial failure of the operating system of the first computer (A), in case of partial failure of one of its peripherals such as its hard disk and for retrieving data from it, or in order to be able to use a single “logical” operating system instance (or operating system image) to operate the different computers using completely heterogeneous hardware.
To be able to boot the first computer (A) with the operating system of the second computer (B), the first computer (A) must be equipped with peripherals (Network Interface Controller (NIC), Hard Disk Drive (HDD), etc) which allows it access to the operating system of the second computer (B), either through a copy of the media containing the operating system files, or a direct connection or an indirect connection.
To perform this operation, it is commonly thought that it would suffice to recover the drivers from the first computer (A) and store them into the second computer (B).
But this is not enough with modern Operating Systems that use internal structures initialised when the devices are detected and then further used to operate said devices without re-detecting them. In order to detect the devices, the operating system component in charge with devices detection and configuration (e.g. Plug'N'Play manager) must be up and running. This component is usually up and running very late in the boot process of the operating system because it relies on a lot of resources provided by said operating system. The component in charge with device detection and initialisation then cannot detect and initialise the boot device controller used to boot the operating system (this problem is commonly known as “chicken and egg problem” in the Information Technology world). Boot device controllers are usually detected and initialised when the operating system is (first) installed. Modern operating systems are usually designed to be installed on a specific computer hardware. Then, moving an operating system already installed to some other kind of hardware is usually not possible because the boot device controllers are not the same and the operating system installed for being used with a specific type of boot device controller cannot be used with another type of boot device controller.
Older operating systems such as MS-DOS® were able to be transferred from one hardware platform to another, because the hardware platforms were fully compatible with personal computer (PC) hardware, whose specifications were publicly available. They were able to use the same sets of instructions to be operated. Some sets of instructions, inherited from these old days, are still usable in modern personal computers (for instance VGA or VESA for graphic adapters, or ATA/IDE for disk drive controllers). The computers are also using standards (actual or de facto) such as PCI bus.
The modern computers, especially the ones still called “PC compatibles”, are still using some of these compatible instructions sets to begin the boot process of the operating system (even a modern one). In particular, they rely on standard BIOS or firmware mechanisms to operate the video, disk drives and keyboard during the very first step of the boot process.
But the modern operating systems need to be able to free themselves from the firmware/BIOS mechanisms used to operate the various devices and components of the computer, in order to be less limited, to be faster, to be truly multitask, to be more efficient etc. Then, the modern operating systems need to operate (control) directly the devices and controllers using device drivers especially developed for a particular operating system to operate a particular device or controller. For instance a modern PC computer will boot using at first a BIOS based video instructions (character mode and then VESA compatible mode) that all the computers of the PC compatible type can use and then, as soon as possible, the operating system will load and initialise a very specific driver for a very specific video controller actually in the computer. This video adapter, though it can be operated through a set of compatible instructions (PC-type or TTY-type character instructions, VESA instructions, etc.), has the best results and performances when using the driver specific for it. For instance, VESA mode cannot be used to display images in 1024*768 with 24 millions of colours per pixel.
A modern computer is often booted off a hard disk drive. A modern PC computer will boot using at first BIOS based disk drive instructions (interruption int13h) that all the computers of the IBM-PC compatible type can use and then, as soon as possible, the operating system will load and initialise the very driver for the very disk drive controller actually in the computer. This makes disk access faster, and makes it possible to use the complete space of the disk drive when the BIOS or firmware may be able to assign only the beginning of it. Using BIOS based instructions, some PC-compatible computers can access only the first 4 GigaBytes of any hard disk drive, when modern computers are commonly using disk drives larger than 40 GB.
However, the operating system can use only one kind of disk drive controller. If some hard disk drive is moved to a computer that uses another kind of hard disk drive controller, even if both controllers can be operated through compatible instruction sets, the operating system on the disk drive will be loaded as long as the compatible set of instructions are used.
When the operating system needs to use the set of instructions specific to a disk drive controller, the operation will fail however if the disk drive controller is not one that the operating system can operate, because the controller does not “understand” the set of instructions that the operating system is able to use to read and write data on the boot disk drive.
Furthermore, modern computers are using chained device controllers and devices and the operating system must be aware of the chain to be able to operate a specific device. For instance, the disk drive controllers in modern computers of the classes IBM-PC™ compatible or Apple Macintosh™ are usually using the PCI Bus interface. The chain then comprises at least PCI Bus controller-PCI interface-Disk Drive controller-Disk drive. The operating system must not only know how to operate each controller, device or interface, but also how this chain is constructed and how each device interacts with the adjacent ones. For instance, the operating system must know in which PCI slot a specific controller is connected. The data related to the chain itself are stored in some internal structures used by the operating system. In MS-Windows™ systems, some of these structures are stored in the system registry. These structures are created and initialised when the device or controller is detected and installed. The structures related to boot devices are initialised when the operating system is installed. The installation procedure of modern operating system usually comprises the loading of a minimal set of components that can use the compatible sets of instructions to operate the computer and that can then load and execute the component in charge of detecting the boot devices and initialising the related structures. When this is done, the computer is rebooted, and the actual operating system is loaded and executed. It is then able of using the suitable specific set of instructions to operate the device controller for the boot device (i.e. to read and load files that contain the rest of the operating system components). Then, the component of the operating system in charge with devices detection and initialisation can be loaded and executed and the rest of the devices that are not required for booting (for instance sound cards, USB controllers etc.) can then be detected and initialised.
One recent evolution of modern operating systems is that they may be able to be completely booted over the network, without requiring the use of a disk drive or a disk drive controller in the computer they operate. Some sets of instructions like the PXE instructions set (defined in PXE specifications), can be used to handle the first part of the boot process (the one that usually relies on BIOS or firmware). From then on, the boot device controller used by the operating system is the Network Interface Controller (NIC). Interestingly, there is no set of compatible instructions for NICs like there are for Video Controllers (VESA for instance) or for IDE Disk Drive controllers (the IDE disk drives can be operated through the eight first instructions of Western Digital's WD1003 Disk Drive controller). PXE is a layer above the network card itself, but PXE instructions set could not be used efficiently to operate a modern NIC in a modern operating system. PXE has been designed only to provide “early steps” boot capabilities to NICs. PXE works at the BIOS level.
Recently, some techniques have been used to allow moving an operating system made for a specific hardware platform to another hardware platform. Several techniques have been implemented to use the compatible set of instructions existing in some devices or device controllers.
Microsoft® Sysprep tool for instance can “prepare” an existing Windows® operating system to be moved to some “unknown hardware platforms” (unknown meaning “currently unknown to the operating system to be moved”). Yet, this tool requires the user to manually provide the drivers and related files for the disk drive controller to be used in the various unknown hardware platforms. Windows® can then be booted on each kind of platform, with a set of minimal capabilities very similar to what the installation procedure would have created if said installation procedure had been run on said hardware platform. Furthermore, the result of deploying an original operating system to various hardware platforms using Sysprep creates as many different logical instances of the operating system as there are hardware platforms. In other words one cannot directly move an operating system previously moved using Sysprep from one platform to another one currently unknown. Furthermore, Sysprep can handle only Windows® operating systems when they are booted using Disk Drive Controllers. It cannot be used with Network Booted Windows® systems.
Another technique makes it possible to build a logical instance of an operating system (a set of files that comprises an operating system and its configuration) that can operate heterogeneous hardware platforms. This technique makes it possible for Windows to boot “unknown hardware platforms” using ATA/IDE compatible mode. Obviously, this technique is restricted to systems that are booted off IDE disk drives. This technique requires that an IDE disk drive is successively moved (or cloned) from one hardware platform to another, and after being moved (or cloned) the IDE disk drive must be used to boot the hardware platform. The operating system can then boot and detect the hardware in the platform it runs on, including the specific disk drive controller in said platform. The operating system must then be configured again to be able to use compatible IDE mode before it is moved to another hardware platform. This technique is used, for instance, in UbiBoot technology of the applicant and also described in Microsoft Knowledge base article #314082
Some operating systems like Linux use “probing”. They embed a plurality of drivers for boot devices (and other devices) and at boot time, the operating system probes the hardware and if a device that is supported is detected (i.e. the device and the driver for this device are present respectively in the computer and in the operating system), then the device can be used. In that sense, this is similar to Sysprep when it is wished to move a system disk from one platform to another. If the disk drive controller that is detected in the “unknown platform” is not in the list of the disk drive controllers that the operating system can operate, the system will not finish its boot process. Linux operating systems often embed drivers that can use compatible set of instructions for boot device controllers using a standard (such as ATA/IDE) to be operated.
SCSI device controllers do not have a standardized compatible instructions set. The SCSI device controllers use standard SCSI instructions set to operate SCSI devices, but the controllers themselves can only be used through “proprietary” instructions sets (Proprietary instructions-SCSI Controller-SCSI Standard Instructions-SCSI devices). Thus, the techniques described above cannot be used to move an operating system using only one specific type of SCSI controller as its boot device controller to another hardware platform using another type of SCSI controller.
Similarly, none of the techniques mentioned above can be used to move an operating system booted off a network server from one hardware platform using one type of network interface controller to another platform using another type of network interface controller.